REMARKS 

Applicant respectfully traverses and requests reconsideration. 

Applicants wish to thank the Examiner for the Notice that claims 8, 16, 27, 36 and 39 
have been allowed and as such the new independent claims based on the original claims have 
been added in this response. 

Claims 1-6, 9-14, 17-25, 28-34 and 37 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Chan et al. The Advisory Action does not appear to have addressed any of 
Applicants remarks in the final Office Action. Accordingly, Applicants respectfiilly reassert the 
remarks from the previous Office Action which among other things request showings in the 
Chan reference for various claim limitations as they do not appear to be present in the cited 
reference and as such the claims are in condition for allowance as they presently stand. 

Chan describes a method and system for secure running of untrusted content. In Chan, 
restricted execution contexts are provided for untrusted content such as email messages and any 
attachments thereto or other information, for example, client processes that are run on a server. 
A restricted process is set up for the untrusted content and actions attempted by the content are 
subject to the restrictions of the process, which may be based on various criteria. Whenever a 
process attempts to access a resource, a token associated with that process is compared against 
security information of that resource to determine if the type of access is allowed. The security 
information of each resource determines the extent to which the restricted process, and thus the 
unrestricted content, has access. The criteria used for setting up restrictions for each untrusted 
content process is information indicative of how trusted or untrusted the content is Ukely to be. 
Chan is directed to a system that can protect against unruly executable content that is 
downloaded, for example, from the Internet. (See for example page 1, para. 0005.) The Chan 
reference does not appear to teach or suggest the claimed method or apparatus since among other 
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things, it does not appear to determine a digital signature verification error such as verifying a 
digital signature of a certificate based on a received message header identifier associated with a 
public key certificate identifier. 

For example, the office action cites page 8, second column, third paragraph and page 9, 
first column, first paragraph and page 10, first column, second paragraph of the Chan reference 
for this proposition. However this portion, for example, does not appear to be directed to a 
digital signature verification process or the detection of an error based on a digital signature 
verification process based on a received message header identifier associated with a public key 
certificate identifier. Instead, the cited portion refers to a calling process being checked to see if 
it is restricted by an appropriate restricted security identifier in a token. However, as understood, 
it does not appear to be performed by a digital signing verification process that is based on a 
received message header ID that is associated with a public key certificate identifier as required 
by the claim. In fact, it does not appear that the described token is digitally signed nor does it 
appear that a message header identifier that is associated with a public key certificate identifier is 
used in any digital signature verification process. As such, the claims are in condition for 
allowance. If the rejection is maintained, Applicant respectfully requests a showing as to which 
data in the cited reference corresponds to, for example, the received message header identifier 
associated with the public key certificate identifier, the digital signature of what entity is being 
verified and which entity perform such digital signature verification and based as an error 
detection performs the step of generating a digital signature verification map. 

In addition, the reference also appears to fail to teach generating a digital signature 
verification map that contains a plurality of acceptable message header identifiers associated 
with the public key certificate identifier. The office action cites to page 8, first column, third 
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paragraph and page 9, second column, third and fourth paragraphs. However, as best 
understood, paragraph 0082 of the cited reference describes for example, that a URL string is 
converted to a restricted security ID through a one-way cryptographic hash function to convert 
the URL string to a restricted security identifier by adding a header indicating that the number is 
a security ID identifier and how the number was generated. In the instance where a binary 
certificate identifier is available for a particular website, then the binary certificate ID is used to 
generate the restricted SID. As such, this portion describes generating a security ID. There is no 
digital signature verification map that includes a plurality of acceptable message header 
identifiers that is associated with the public key certificate identifier. In fact, it does not appear 
that any digital signature verification operation is described nor is there a reference to a plurality 
of acceptable message header identifiers that are contained in a digital signature map as required 
by the claim. Accordingly, the claims are also in condition for allowance based on this reason as 
well. 

Moreover, the portion in page 9, such as paragraph 0093 and 0094 refer to a sender 
sending an email message and that the email may include a digital signature that may be used to 
verify that the sender is the source of the message. However, again there is no digital signature 
verification map that is generated nor any digital signature verification map that contains a 
plurality of acceptable message header identifiers that are also associated with public key 
certificate identifiers. As such, the claims are believed to be in condition for allowance. 

As for claims 2, 5, 21, 24, 30 and 33, Applicant respectfully reasserts the relevant 
remarks made above and also respectfully submits that the cited portion of the reference appears 
to simply refer to the fact that a restricted security ID is placed in a restricted security ID field of 
a restricted token wherein the restricted security ID may be a hash value that may include a 
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certificate identifier of a website. However, again there does not appear to be any generation of 
a digital signature verification map that stores an acceptable message header identifier as a map 
entry in response to determining the digital signature verification error . For example, there does 
not appear to be an updating of a digital signature verificafion map when a digital signature 
verification error is determined. To the contrary, since there is no digital signature verification 
error being determined based on a received message header identifier, the claims are in condition 
for allowance. 

As to claims 3, 22 and 31, Applicant respectfully reasserts the relevant remarks made 
above with respect to the relevant independent claims and also respectfully submits that the cited 
portion fails to describe mapping of a plurality of acceptable message header identifiers on a per 
certificate subject identification databases . Again, since there is no determination of a digital 
signature verification error and a subsequent generating of a digital signature verification map, 
these claims are also believed to be in condition for allowance. 

As to claims 4, 10, 12, 18, 23 and 32, Applicant respectfiiUy reasserts the relevant 
remarks made above with respect to the relevant independent claims and also again note that the 
cited reference does not appear to generate a digital signature verification map that contains a 
plurality of accepted message header identifiers associated with the public key certificate 
identifier after determining that a digital signature verification error has occurred. As such, there 
is no verification of a digital signature based on a digital signature verification map as required in 
these claims. Accordingly, these claims are in condition for allowance. 

As to claims 6, 14, 25 and 34, Applicant respectfully reasserts the relevant remarks made 
above with respect to the relevant independent claims. 
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As to claims 9, 1 1, 13, 19, 28 and 37, the office action cites page 8, second column, third 
paragraph as teaching that a step of determining a digital signature verification error includes 
comparing the public key certificate identifier with a mismatch as detected. However, the cited 
portion of the reference does not teach comparing a public key certificate identifier with the 
message header identifier to determine if a mismatch is detected. In fact, the only reference to a 
certificate is the binary certificate ID. However, this portion teaches that such a binary 
certificate ID is used in a hash function to generate the restricted security ID. There is no 
comparison of a pubhc key certificate identifier and message header identifier to determine if a 
mismatch is detected. Moreover, the claim requires that if a mismatch is detected, then a 
mismatch notification is generated for an operator and a digital signature is verified based on a 
verification key associated with the public key certificate identifier. No such mismatch 
notification appears to be taught or suggested nor a verification process as claimed. As such, this 
claim is also beheved to be in condition for allowance. 

Claims 7, 15, 26 and 35 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Chan. It appears that the office action admits that Chan fails to disclose a digital signature 
of a digital signature verification map to provide a trusted digital signature verification map. 
However, another section of Chan has been cited as allegedly being properly combinable to 
render Applicant's invention obvious. The cited portion in Chan is directed to the digital 
signature of an email message to ensure that the message is trustworthy. However, it also 
appears that the office action is attempting to equate a digital signature verification map with the 
"restricted token" in the Chan reference. However, as noted above, there is no digital signature 
verification process that is used to generate the restricted token in a manner as claimed by 
Applicant. Accordingly, the claims are in condition for allowance based on the reasons given 



CHICAG0/#1 3077 19.1 



18 



above. Moreover, using selected portions of the Chan reference thereof to render Applicant's 
claimed invention obvious does not appear to be proper since there is no motivation to combine 
disparate teachings. In fact, if it was obvious, it is curious why Chan did not describe such a 
system. For example, as admitted by the Patent Office, the restricted tokens as described in 
Chan do not appear to be signed by any trusted authority, yet Chan describes elsewhere that 
emails are digitally signed. Accordingly, Chan did not contemplate utilizing a digitally signed 
restricted token and as such, using Applicant's invention as a roadmap appears to be improper. 
For these reasons also, the claims are believed to be in condition for allowance. 

Applicants have added new claim 45 which depends on claim 38 which addresses the 
comments made in the Advisory Action as indicated to be allowable. As such, this claim is also 
believed to be in condition for allowance. 

Accordingly, Applicant respectfully submits that the claims are in condition for 
allowance and that a timely Notice of Allowance be issued in this case. The Examiner is invited 
to contact the below-listed attorney if the Examiner believes that a telephone conference will 
advance the prosecution of this application. 



Vedder, Price, Kaufman & Kammholz, P. C. 

222 N. LaSalle Street 

Chicago, IL 60601 

PHONE: (312)609-7599 

FAX: (312) 609-5005 

E-MAIL: creckamp@vedderprice.com 



Respectfully submitted. 





Christopher J. Reckamp 
Registration No. 34,414 
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